A multiplicity of electronic devices for consumers and for professional use are provided with software necessary for their operations. Such software is typically installed by the manufacturer in protected areas of the device, to prevent them from being downloaded and copied. Commonly, programs installed within electronic devices are known as firmware.
The performance of an electronic device depends to a large extent on the installed firmware or software. The same devices can be provided with ever more advanced software or firmware, both to eliminate the flaws of previous releases of the software, and to carry out new functions, or improve existing functions.
Today, technology enables easily to update the programs (software and firmware) on electronic devices once they are installed by the customer. All this is now considered a given fact and above all a “must-have” item by any type of customer, whether it be a large company or a home user of a given electronic apparatus or device. Consider how it is now commonplace to update one's CD reader, video games console, home router with new firmware supplied from time to time by the manufacturer of the device. For operating systems and application software, e.g. programs for word processing, video and image processing, electronic publishing, accounting and other purposes, continuous updates and advances are available, which are also offered online to the owners of the respective electronic devices that use them, e.g. computers, mobile telephones and others.
For security and marketing reasons, device manufacturers need to protect their product while still enabling users to update the purchased product remotely, through the new software or firmware as it becomes available.
Normally, the channel, or in general the path followed by a new software update from the time it leaves the enterprise to the time it reaches its intended recipient is neither protected nor secure. For this reason, enterprises try to protect their firmware or software by encrypting it, using suitable encryption algorithms for the purpose.
Recently, customized software or firmware update technique has been introduced. According to this technique, the software manufacturer adopts suitable measures to ensure that an updated firmware or software can only be sent to a single device. When the supplier or manufacturer of the software or firmware adopts an approach of this kind, the updated software or firmware must be received, e.g. by downloading it from the Internet, once for each device to be updated. Situations of this kind are typically experienced, for example, in the case of a plurality of computers connected to a company network. Each computer must download the software or firmware update, e.g. the update of the operating system or of an application. In such a case, the same update must be downloaded through the Internet connection as many times as there are computers connected to the local network.
There are many techniques to carry out this process of individually upgrading each device. For example, the update can be controlled using a different encryption code for each device to be updated. Otherwise, hardware or software keys to be applied to the device may be provided; they may be made in such a way that they can only interface with one specific device. In this case, for example, the hardware key may be fitted with a microcontroller to read data or codes of the device with which the key is interfaced the first time, and to prevent the key from operating if it is connected to a different device.
If the update of a software or of a firmware, i.e. of a generic program on an electronic device, for security and data protection reasons is carried out with a technique that requires sending a different software for each electronic apparatus or device, high costs will be incurred in terms of data processing or of transmission bandwidth utilization.
For example, let it be supposed that an installation has a plurality of electronic devices, which must be updated, and a collection point that connects them to a data center able to provide the software updates to be installed on individual devices. An installation of this kind may comprise a photovoltaic farm, in which each panel is associated with an electronic device that exchanges information with a data collection unit. The data collection unit is manufactured and programmed to collect information about the proper operation of individual panels by interrogating the electronic devices on the panels and to communicate with a remote-operation or supervision center. A similar situation can be represented by a public lighting system, comprising a plurality of light fixtures, each of which can be associated to an electronic device, e.g. able to verify the proper operation of the light fixture, and/or to command it to be turned on and off and/or to dim it. The electronic devices of the individual light fixtures can be connected, e.g. through a power line communication system, with a data collection unit, which dialogs with the individual electronic devices. The collection unit, in turn, can be connected with a remote-operation or supervision center, to which the data collected by the unit are transmitted, and/or which can send commands or queries to the individual electronic devices.
In a scenario of this kind, every time it becomes necessary to update the software or firmware on the electronic devices, the collection unit must receive the same software or firmware from the remote-control or supervision center as many times as there are devices to be updated and said software or firmware must be encrypted every time with an encryption key for each device. Supposing that the installation comprises N identical devices to be updated, in practice the control unit would have to download N times the same update only because it is physically encrypted in a different way for each device. This is a problem in itself, because it requires the transmission of a large quantity of data.
Moreover, since the electronic devices are typically connected to a bus, or to another shared transmission communication channel, said bus is utilized to communicate all the N programs to the various devices, remaining occupied a long time to perform this function. If the firmware or software were single, the control unit could download the firmware of software only once and transmit it to all the electronic devices also in broadcast mode at once, i.e. transmitting it only once on the bus or other transmission channel.
The primary function of the control unit is to monitor and manage the electronic devices connected to it, and the communication bus has to be occupied mainly for monitoring and signaling and for the management of the operating problems of the controlled electronic devices. From this viewpoint, a remote update can be considered a secondary functionality, to which the least possible amount of time and resources should be dedicated. This requirement is in contrast with the need to transmit the updated software as many times as there are devices: such a need is determined by the need to transmit the software or firmware under secure conditions.
FIG. 1 shows a diagram of a system according to the prior art. The reference number 10 indicates a data center, e.g. a server, used, among other purposes, to contain the upgrading files (e.g. firmware) of a plurality of devices 1, 2, . . . i, . . . n−1, n, which are connected to a transmission bus 11. The bus 11 in turn is connected to a block 12 which represents a controller, a datalogger and an interface and a generic transmission channel 13, which connects it to the server, e.g. the Internet. For data protection reasons, the files are transmitted from the server 10 to the controller 12 in encrypted form. If C is the chosen encryption algorithm and Fw the firmware in clear to be encrypted, the size of the encrypted firmware will be equal to or greater than the original firmware. Typically, on a firmware of large size, the size increase of the file as a consequence of encryption is nearly negligible. For example, with the 128-bit AES algorithm (http://it.wikipedia.orq/wiki/Advanced_Encryption_Standard), the size of the encrypted object is a multiple of 128 bits, i.e. 16 bytes. Hence, if the original firmware is 10 bytes, the result will be 16 bytes. If instead the firmware is 15000 bytes, the result will be 15008 (first multiple of 16 subsequent to 15000). Therefore, for large numbers, the unencrypted firmware and the encrypted firmware have comparable size. Therefore, it can be considered thatDim(Fw)=D≅Dim(C(Fw,Kj))=DCF  (1)whereDim(Fw) is the size of the unencrypted file (firmware);Dim(C(Fw, Kj) is the size of the encrypted file (firmware);Kj=f(RNDj, . . . ) is the encryption key, which by way of example may be represented by a one-directional function of a string of bits, a part of which is represented by a random number RNDj. This number is different for each jth device, since each encrypted firmware is intended for one specific device and not for the others.
Hence, encryption does not substantially change the size of the firmware to be transferred.
Let WC be the weight in bytes of a data exchange on the communication channel between server 10 and controller and let WB be the weight in bytes of a data exchange on the bus 11 between controller 12 and each device 1 . . . n. With the transmission technique according to the state of the art, in which each jth device receives a firmware encrypted with its own Kj encryption key, the traffic in bytes TC on the communication channel 13 shall be equal toTc=Σi=1n(DCF+WC)=n(DCF+WC)  (2)Similarly, the traffic in bytes TB on the internal bus 11 will beTB=Σi=1n(DCF+WB)=n(DCF+WB)  (3)It must be taken into consideration that the workload of each jth device will not only be the one necessary for the update, but also the one required to process and discard all (n−1) update communications received by the other devices connected to the bus. Typically, since the channel 11 is a shared bus, all devices 1 . . . n “listen” to the entire communication regardless of whether it is addressed to them or not.